1. Field of the Invention
The invention is in the field of electronic design automation (EDA), and more particularly, is related to cell libraries for efficient modeling of device properties.
2. Related Art
An electronic design automation (EDA) system is a computer software system used for designing integrated circuit (IC) devices. The EDA system typically receives one or more high level behavioral descriptions of an IC device (e.g., in HDL languages like VHDL, Verilog, etc.) and translates (“synthesizes”) this high level design language description into netlists of various levels of abstraction. A netlist describes the IC design and is composed of nodes (functional elements) and edges, e.g., connections between nodes. At a higher level of abstraction, a generic netlist is typically produced based on technology independent primitives.
The generic netlist can be translated into a lower level technology-specific netlist based on a technology-specific (characterized) cell library that has gate-specific models for each cell (functional element). The models define performance parameters for the cells; e.g., parameters related to the operational behavior of the cells, such as power consumption, delay, transition time, and noise. The netlist and cell library are typically stored in computer readable media within the EDA system and are processed and verified using many well-known techniques.
Before proceeding further with the description, it may be helpful to place these processes in context. FIG. 1A shows a simplified representation of an exemplary digital ASIC design flow. At a high level, the process starts with the product idea (step E100) and is realized in an EDA software design process (step E110). When the design is finalized, it can be taped-out (event E140). After tape out, the fabrication process (step E150) and packaging and assembly processes (step E160) occur resulting, ultimately, in finished chips (result E170).
The EDA software design process (step E110) is actually composed of a number of steps E112-E130, shown in linear fashion for simplicity. In an actual ASIC design process, the particular design might have to go back through steps until certain tests are passed. Similarly, in any actual design process, these steps may occur in different orders and combinations. This description is therefore provided by way of context and general explanation rather than as a specific, or recommended, design flow for a particular ASIC.
A brief description of the components steps of the EDA software design process (step E110) will now be provided:
System design (step E112): The designers describe the functionality that they want to implement and can perform what-if planning to refine functionality, check costs, etc. Hardware-software architecture partitioning can occur at this stage. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include Model Architect, Saber, System Studio, and DesignWare® products.
Logic design and functional verification (step E114): At this stage, the VHDL or Verilog code for modules in the system is written and the design is checked for functional accuracy. More specifically, the design is checked to ensure that it produces the correct outputs. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include VCS, VERA, DesignWare®, Magellan, Formality, ESP and LEDA products.
Synthesis and design for test (step E116): Here, the VHDL/Verilog is translated into a netlist. The netlist can be optimized for the target technology. Additionally, the design and implementation of tests to permit checking of the finished chip occurs. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include Design Compiler®, Physical Compiler, Test Compiler, Power Compiler, FPGA Compiler, Tetramax, and DesignWare® products.
Design planning (step E118): Here, an overall floorplan for the chip is constructed and analyzed for timing and top-level routing. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include Jupiter and Floorplan Compiler products.
Netlist verification (step E120): At this step, the netlist is checked for compliance with timing constraints and for correspondence with the VHDL/Verilog source code. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include VCS, VERA, Formality and PrimeTime products.
Physical implementation (step E122): The placement (positioning of circuit elements) and routing (connection of the same) occurs at this step. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include the Astro product.
Analysis and extraction (step E124): At this step, the circuit function is verified at a transistor level, this in turn permits what-if refinement. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include Star RC/XT, Raphael, and Aurora products.
Physical verification (step E126): At this step various checking functions are performed to ensure correctness for: manufacturing, electrical issues, lithographic issues, and circuitry. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include the Hercules product.
Resolution enhancement (step E128): This step involves geometric manipulations of the layout to improve manufacturability of the design. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include iN-Phase, Proteus, and AFGen products.
Mask data preparation (step E130): This step provides the “tape-out” data for production of masks for lithographic use to produce finished chips. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include the CATS(R) family of products.
In general, a characterized cell library can be used in the steps of synthesis, design planning, netlist verification, physical implementation, and analysis (as indicated by the bolded chevrons).
FIG. 1B illustrates an example cell 100. Cell 100 represents an AND-OR-Invert (AOI) gate formed by AND gates 110 and 120 and an OR gate 130, with the outputs of AND gates 110 and 120 being tied to the inputs of OR gate 130. A characterized library entry associated with cell 100 would typically include performance parameter information for cell 100 across a range of operating conditions. For example, because each of AND gates 110 and 120 includes two inputs, cell 100 includes at least four paths (i.e., input 111 to output 133, input 112 to output 133, input 121 to output 133, and input 122 to output 133) for which delay, power, noise, and other performance parameters can be specified.
The performance parameter data associated with the cells in a characterized cell library is typically provided across a range of operating parameter values (e.g., values for input slew, output capacitance, voltage (e.g., cell operating voltage), and temperature), and can be provided by a foundry or can be calculated via a simulation program such as SPICE. The performance parameter data therefore may originally be compiled as a set of discrete data points.
For example, FIG. 1C, shows a sample performance parameter table 101 for one timing arc of the timing path from input 111 to output 133 of cell 100 (shown in FIG. 1B). For example, the timing arc could be the fall/rise delay arc or the fall/rise transition time arc. For the sake of simplicity, the timing arc is shown as a function of two operational parameters, although in other embodiments, the timing arc could be a function of any number of operational parameters (if more than two operational parameters are considered, a multi-dimensional table or multiple two-dimensional tables would be required).
Table 101 could be an entry in a cell library, and includes performance parameter values PP11-PP46 and two sets of operational parameter values X1-X6 and Y1-Y4. Performance parameter values PP11-PP46 can represent values for any single type of performance parameter (e.g., delay, noise, or power consumption), operational parameter values X1-X6 can represent values for a first operational parameter (e.g., input slew, output capacitance, temperature, or voltage), while operational parameter values Y1-Y4 can represent values for a second operational parameter.
Each performance parameter value is referenced by a particular combination of operational parameter values (i.e., performance parameter value PP11 is generated by the combination of operational parameter values X1 and Y1). Thus, for example, PP11 could represent the delay from input 111 to output 133 for an output (load) capacitance X1 and an input slew Y1. Note that interpolation or extrapolation may be required if the desired operational condition (i.e., the desired combination of operations parameter values) is not listed in the table. For example, if the operational parameter values are X5 and Y5, with X1<X5<X2 and Y2<Y5<Y3, then PP21, PP22, PP31 and PP32 may be used to calculate the performance parameter value at (X5,Y5) using interpolation.
Note that while performance parameter table 101 is relatively small for exemplary purposes, typical performance parameter tables will be much larger, as performance parameter values will be provided for many more combinations of operating parameter values in order to produce more accurate performance information and/or provide improved interpolation/extrapolation capabilities. Therefore, look-up tables can consume relatively large amounts of storage space and memory resources within an EDA system. For example, a single library can contain tens of thousands of look-up tables. In addition, each look-up tables may require a large number of data points if high interpolation and/or extrapolation accuracy is desired. The resulting large number of large lookup tables can be cumbersome for EDA tools (e.g., synthesis or analysis tools) and can significantly increase computational requirements and modeling time. Therefore, modern characterized cell libraries may choose to replace lookup tables with mathematical models (typically SPM formulas) of cell behavior.
For example, some early mathematical models of functional element timing were based on fixed-form linear equations of input slew and output capacitance load. Later, these timing models (e.g., for generic CMOS) were based on a linear equation including both of these two variables (with fixed coefficients) and, similarly, the same linear equation form was used to model all of the gates of a given technology library. Although the linear equation form was the same for all gates, the coefficients of the linear equation could change from timing arc to timing arc within the same technology library. This allowed the timing calculations to be generalized across the entire technology library and thereby made the timing calculations easier to perform. However, the calculations were not entirely accurate because some library gates were not well modeled by the fixed-form linear equation.
Recently, advanced cell libraries have begun to incorporate scalable polynomial-based models (“SPM models”) to specify cell performance parameters, as described in co-owned U.S. Pat. No. 6,732,341, issued May 4, 2004 to Chang et al., herein incorporated by reference. Replacing look-up table models with polynomial models significantly reduces memory usage, while increasing computation speed for tools that make use of the cell library (e.g., synthesis tools and static timing analysis tools).
For example, FIG. 1D shows a sample cell library entry 102 generated from table 101 in FIG. 1C. The performance parameter values associated with each different combination of operational parameter values (X1-X4 and Y1-Y4) have been replaced with a polynomial function FN1 of operational parameters X and Y. Typically, a predetermined polynomial form is used for function FN1, so that only the coefficients of the polynomial function FN1 are stored in the library. In doing so, the size of cell library entry 102 can be significantly reduced over table 101 shown in FIG. 1C.
The particular form of polynomial function FN that is used for modeling purposes is typically selected from a set of scalable polynomial systems (e.g., the decomposed Taylor Series and the Joint Taylor Series), and can have different orders (e.g., first, second, third, etc.) with respect to the input variables. The lower the orders used in the polynomial forms in a library, the less computationally expensive are the analyses performed using that library.
For example, if the order of the polynomial using decomposed Taylor series is 2 (i.e., the highest order for each variable in the polynomial form is 2), and the function has 4 operation parameters, the total number of polynomial terms is (2+1)4=81. However, if the order of the polynomial is 3, the total number of polynomial terms jumps to (3+1)4=256. Therefore, it is extremely beneficial to limit the order of the library polynomial forms to minimize the number of polynomial terms, thereby minimizing polynomial model derivation and usage complexity.
However, as device sizes continue to shrink, the performance parameters of those devices become more nonlinear, and hence more difficult to fit with conventional polynomial models. Although high-order polynomials or piecewise polynomials may be used to achieve better fitting accuracy, both have limitations. High-order polynomials require more terms and have the undesirable high-order oscillations that may cause large errors in certain fitting regions of performance parameter data. Piecewise polynomials can avoid such oscillations, but can require a large number of polynomials to provide an accurate fit.
In either case, the large number of coefficients of both high-order polynomials and piecewise polynomials can make such approaches unattractive solutions to the problem of excessive library size and computational requirements. These shortcomings of high-order polynomials and piecewise polynomials only become more pronounced as device sizes continue to rapidly scale down and more operational parameters start to affect performance parameters.
Furthermore, it is well known that a polynomial form has difficulty in accurately modeling/representing certain very nonlinear behavior (e.g., exponential functions). In such cases, a conventional scalable polynomial representation of the data is neither efficient nor robust.
Accordingly, it is desirable to provide a method and system that can accurately model all types of performance parameter distributions without significantly increasing computational and storage requirements.